Volume 1

Issue 3

September 2004

Gaining Management Support Building a Business Case for Content Management Steve Huffman Janice Jones Medtronic Core Neurological Medtronic Core Neurological stephen.huffman@medtronic.com janice.annjones@medtronic.com This article provides direction for those seeking to build a business case for a content management system (CMS) in a specific functional area of an organization. While there may be resources in your organization to help you with technology and automation projects, in most cases you need to drive the initial efforts from your functional area. You are the subject matter experts, you know the issues you are up against, and what to do to solve them. Getting others in your organization-where there are so many needs and so many things to do-to listen and to allocate resources is the difficult part. But, if you go about building your business case the right way, it can go a long way toward building credibility, raising visibility, and making your CMS implementation a reality. Introduction For a small technical communications group in a large medical device company, gaining management support and approval for implementing a content management solution was not a simple matter of selling an "efficiency and savings" project to management and securing some funding. Instead, the path to approval, and ultimate implementation of a content management system (CMS) involved a tremendous amount of time, energy, resources, and diligence to build a compelling and highly focused business case. We needed a business case that was clear, simple, and smart enough to attract interest and support, yet detailed enough to meet organizational requirements for what was, essentially, an information technology (IT) initiative. To do so, the business plan had to include a finite scope, identify issues at the root cause level, and present objectives to address each issue. The approach to identifying the solutions and the recommended technology choices had to link directly to the problems and objectives and be aimed at delivering tangible, cost-returnable benefits. Return on investment (ROI) had to be measurable, attainable in the short-term, and it needed to come solely from the technical communications functional area. Identifying the high-level need When you start, you may know only two things: You "need" a content management system The high-level, philosophical arguments for content management that you read about on websites and hear about at industry conferences will not suffice to convince potential purchasers or users of the system that it is needed, let alone to secure the funding or resources you require So you need to start at the ground level. Before anything else, you must: Gain a thorough understanding of your situation (to begin building credibility) Achieve buy-in from the would-be users and ensure them that they will "create" the system solution by defining what it needs to do, and how it does it Educate management and other decision makers in your organization on content management and its potential direct and measurable benefits for your business The fastest, most effective way to achieve all these goals at once is to contract with an industry expert (consultant organization) for a needs analysis and recommendation. From a third-party industry expert, you get a baseline of where you stand, the general causes behind some of your greater problems, and possible options for addressing them. And, it will likely get you the buy-in from your functional area staff, as these would-be users of a CMS will finally have someone who understands their issues, and maybe more importantly, someone who can document them objectively for sharing with others. Digging deeper: getting to the root of the problems Quite often, the core issues identified in an industry-expert analysis are wide-ranging, cross-organizational, and simply too complex to resolve all at once. If you are a single department looking for answers-with no ability or desire to drive sweeping cross-business process and cross-organization change-then the issues and recommendations, while interesting to management, are not ones that you can take forward. You need to dig deeper before you can begin building your case. You need to thoroughly analyze what your functional area does and how it does it. One approach is to create an end-to-end, step-by-step map of what it takes to generate a single instance of your end product (for instance, a published document). Breaking down formal department processes, instructions, and forms that are completed is only part of it. The other half is identifying all the informal user steps, tasks, and activities that go on day in and day out but remain undocumented, unrecognized, and accordingly, not officially identified as part of your area's resources from an organizational standpoint. Creating an end-to-end, itemized activity breakdown of your process is only part of digging deeper. You need to identify where "what you do" and "how you do it" is preventing you from doing your job effectively and efficiently for the organization. A simple method of evaluating might be to give weight to each step. How much resource does it consume (its burden)? How often is it done (its frequency and repeatability)? Simple weighting (such as 1, 2, 3, for low, medium, high) helps find the items that bog down a department, and the core issues and problems you need to focus on at the root of your business case. For instance, you may find that a simple (not very burdensome), previously undocumented, informal task may be repeated many times during the lifecycle of a document (and will get a high repeatability weight of 3). The high repeatability rating shows the task as being one you need to address. The desired outcome of digging deeper is a clear picture of what needs to be fixed and what works fine as is-at a granular, task level. Finding real ROI The burdensome and repeatable steps can become the core drivers of your proposed return on investment. Using these specific, detailed metrics, you can analyze how and where your cost center dollars are being spent: Are writers really writing, or are they spending 60 percent of their time on administrative tasks that are either very burdensome or often repeated? From your end-to-end analysis, you need to determine what types of savings (for instance, in person-resource hours) can be associated with fixing some of the glaring root problems you identified. Knowing where your cost center is lean versus where you are drowning (often, unknown to you prior to this point) in resource allocation is critical in determining where you will focus your project efforts and direction. You need to go after real, measurable, and attainable ROI, mapped directly to issues identified in your end-to-end analysis. ROI related to specific activities, issues, or problems provides other benefits as well. You now have solid evidence to avoid a potential solution path that targets things you were doing effectively and misses the areas and items you really need help addressing. You gain credibility within your organization by demonstrating that you understand the workings of your functional area and cost center at an in-depth level. You know and are able to articulate how efficient, or inefficient, you are at providing your core competencies to the organization. Identifying the risk An analysis of how your department works at the step level begins to identify where the areas of "risk" are in your process and day-to-day project workflow. But risks don't always sell well to management, as the consensus can be to "keep doing what you're doing because you've been getting it right, with no problems, so far." However, risk can resonate if you can find the right projects coming down the pipeline. What are the highly-visible initiatives that could result in higher costs to both the organization and to customers if things go "wrong" in your area? Measure those risks, determine what the potential costs might be if risk becomes reality, and in turn, show how the risk can be mitigated by addressing the areas of concern you have identified. Crafting the case Armed with metrics, ROI, and an assessment of risk associated with real business initiatives, you are ready to involve management to help you craft the case. Your situation begins to look real and compelling to your management team because you have detailed research, analysis, and current cost and future ROI numbers. Management sees that you are going after the right issues, and are chasing the most significant ROI. You've bridged the gap from months ago when you had only high-level analysis and recommendations to show them. Your management team knows what will sell, and what will not, and seeing that you have plenty of data and metrics available, they will want to help you build and sell your business case. Your management team (along with input from other areas, such as IT, quality, and finance) can help you prepare the appropriate style of business case that typically works in your particular organization. The business case style we used was a stepped approach. We built our case in steps or components: a problem statement; a set of goals and objectives to address those problems; an approach that describes how to meet the goals/objectives; recommended steps to take; and finally, the recommended solution. This stepped approach worked well in our environment for a number of reasons: As we gathered input and solicited assistance, by working on the steps one at a time in a linear fashion, we could keep those who were helping us (management, IT, others) focused. The completion of each step in our business case built credibility with our management team and with other key decision-makers, such as IT. During the presentation stages, we had our situation chunked into bites that were concise, presented easily, and could be understood by various types of audiences. As we gained approval for each component in our business case, we essentially created "bankable" items. For example, once we gained agreement on our problem statement and objectives, we would not need to revisit or rework them. Credibility of our case built with the approval of each step, making the final approval of our ultimate recommendations a much more logical progression of events. A stepped approach might be constructed as follows: Problem statement: You have all the problems identified, but you need to sift that information down to a small set of easy-to-grasp issues that can be taken forward. All the research, analysis, documentation, and metrics must be honed down to a concise problem statement (for example, four or five bullet points), each one with direct supporting data. Once you have these common problems identified and your next-level manager's support, they become the root of your battle cry, or the repeatable message that will follow your project through planning and implementation. The problem statement is the first thing that resonates up and across the organization. If done well, others will start speaking your battle cry for you. Objectives: For each component in your problem statement, articulate a clear, and directly matching, objective to solve that problem. Objectives are not tool solutions to the problems, but rather what your functional area has determined should be done to address each problem. Again, you are working on building credibility within your organization, and you must be sure you are not just telling management to buy some expensive software or system that "can fix everything." This is not the appropriate time to be recommending a solution, and if you appear to be, it will be obvious. But you can start setting expectations by mentioning terms like "technology" and "automation," in the sense that you need to "leverage" them as part of your solution. Approach: Show management an approach (the optimal way) to meet each objective. The approach is likely to be the first time you start talking a little bit about tools and technology. For an objective that is something like "leverage technology" or "leverage automation," your approach can include "going out and looking at what technology might be available, both within the enterprise and in the general marketplace. This is clearly the place to make it known that you are going to research software, systems, etc., that will need to be purchased, thus continuing to set expectations. Your organization is likely to buy in to the "looking at software and systems" part of your approach because they agreed with and approved your problem statement and objectives. Your approach must also include a timeline that shows the at-risk projects you identified, and that your objectives can be implemented before those projects suffer. You need to point to the calendar and identify for managers, finance, and other key decision makers, the point at which you are likely to need funding (assuming all goes well and your ultimate recommendations are approved) in order to head off the risks you identified earlier. The timeline also provides the vehicle for you and key approvers in your organization to start talking about the potential amounts of money this effort will require-in ballpark terms only, as you have not done any tools research. But you need to have the discussion about budget so that you get the commitment from management that they are willing to allocate and approve the (general) estimates in the defined timeframe, if the ultimate recommendation is one they can support and the ROI is there to fund it. It is critical to set expectations about time and money. Do not hide potential dollar amounts. You must gain at least a head-nod for the ballpark expenses (which should be easy to obtain since you showed your ROI is real). Recommended steps: Define the "next steps" that you are asking your management team to support. It must be clear to management that you are going to do the necessary research and investigative work and come back with a recommended solution. Showing "next steps" gets you a firm "OK" for your approach, and the backing from management to investigate and define the recommended solution. Your project's official recognition by management may also be a key to your gaining access across the organization to resources you need (again, such as IT, finance) to get your research done and build your recommendation. The desired outcome is: Agreement and approval: Agreement with your problem statement and goals/objectives, and approval for your approach and recommended steps. This gives you the clearance (really, the authorization) to do your work and return with a recommended solution. Accomplishment of expectation setting: Agreement and approval makes it clear to decision makers that you will be returning with a recommended solution. Your timeline (based on the future risks that need to be addressed) shows when you will be coming back with the recommendation, and that you expect them to act on it when you do. Alternatively, if they do not want you to do the work and identify the solution, they need to tell you at this point. Preparing the recommendation After having done so much work to sell your project, it is critical that the solution you propose includes spending money on tools and technology that will solve your "real" problems-those in the problem statement-and thus meet the goals and objectives you committed to, and provide the ROI needed to pay for it. With the appropriate organizational approvals, the challenge now is to gather the necessary input from your users and draft your requirements. As you gather these requirements (and there will be many), go back to your detailed department analysis work and associate the requirements with the items where you identified the opportunity for greatest improvement, and the most significant ROI. By linking back to that detailed department activity level, your requirements will align with your problem statement, overall ROI, and goals/objectives. Matching requirements with ROI and previously identified critical problem areas also ensures that you remain on target as you assess technology and tools. You will be able to press the software and systems providers on whether their systems and solutions can deliver what you need, and where you need it. In other words, you are much less likely to purchase a system that completely misses the mark. To facilitate the processes of gathering requirements and obtaining systems and software information from vendors, leverage resources within your organization that have these competencies. Work with areas such as IT and procurement, which regularly assemble requirements and solicit vendor proposals. If you have to do the work yourself, ensure you follow the protocols for the requirements and selection processes used by those areas. Ensure that you follow the organizational standards for documenting requirements, preparing a statement of work, issuing requests for information/proposals (Riffs/Riffs), and scoring and assessing the vendor submissions. This will avoid a scenario in which you are told to do the work over because you did not follow standards for this activity. Furthermore, following protocol and standards continues to build your credibility. If requirements are correctly prepared and defined, the ultimate solution, including system and software selection, will be obvious to you and the critical decision makers in your organization. With everyone having supported you to this point, they now have a stake in your success-and none of them will want to push you in an alternative direction that might result in failure (for you, for them, or for the organization). At the point when you are finally asking for final approvals and signatures for funding, support for the recommended solution will run deep and wide across your organization. Summary The result, a properly developed business case, will help you gain the multi-level and cross-functional support and sponsorship needed to promote your initiative through the rigorous scrutiny of the approval process and secure the necessary funding. Those same sponsors will ensure that the infrastructure and organizational support are properly allocated and in place as you move ahead, avoiding new obstacles and surprises down the road to implementation. For you, what this might mean is that the most difficult work has been completed before the project activities even get started.